지난 오픈소스 기여 활동 회고에서는 본인이 기여하고 싶은 오픈소스를 선정하는 과정을 정리해봤다. 이번 글에서는 내가 선택한 오픈소스인 elasticsearch-java의 이슈 3개, 그리고 elasticsearch 의 이슈 1개에 대한 설명과 선택한 이유, 그리고 인제님의 피드백을 정리해보겠다.
선정한 이슈 소개와 해결방법 함께 논의
elasticsearch-java
이슈 1
- 이슈 설명
서버 사이드 코드에서 empty object를 반환하는 경우, java client의 JsonpDeserializer.fixedValue(T) 코드는 이를 제대로 입력받지 않기 때문에, emptyObject(T) 함수를 사용함으로써 정상적으로 입력받도록 할 수 있다. SimulateIndexTemplateResponse 클래스에서도 fixedValue를 사용하는데, 서버 사이드에서는 SimulateIndexTemplateResponse는 json형태의 content를 지니고 있기 때문에 emptyObject로 수정하기를 권고하고 있다.
- 선정 이유
서버 코드와 클라이언트 코드에 대한 레포를 둘 다 고려해야 해결할 수 있는 이슈여서 엘라스틱 서치의 로직을 더 깊게 학습해볼 수 있는 이슈여서 마음에 들었다.
- 피드백
인제님꼐서는 서버 사이드 코드를 살펴보시더니, 해당 링크를 나에게 보내주셨다. 클라이언트 코드에 대한 테스트는 어떤식으로 이뤄지는지를 살펴봐야한다고 하셔서, elasticsearch-java의 test 폴더를 살펴봤다.
test > co/elastic/clients/elasticsearch
해당 경로에 security 폴더가 없어서 당황했지만, 인제님께서는 end_to_end 테스트는 존재해서 이를 참고해보면 좋지 않을까라고 말씀해주셨다.
이슈 2
- 이슈 설명
name 인자가 DateHistorgramAggration builder에 있으면 “the content is invalid” 에러를 반환하므로, builder에서 name 생성 부분을 제외해야한다는 이슈이다.
- 선정 이유
이슈 1에 비해 수정해야할 부분이 간단해서 선정하였지만, 해당이슈는 client코드가 아닌 elasticsearch-specification을 수정하는 방향이 더 적합하다는 댓글이 있어서 애매하였다.
- 피드백
인제님께서도 2번 이슈는 es spec변경이 우선되어야 해서 진행이 불가능할 것 같다고 말씀해주셨다.
이슈 3
- 이슈 설명
WriteResponseBase 클래스의 primaryTerm과 seqNo 필드가 null을 반환할 수도 있기 때문에, 기존 long타입을 Long타입으로 수정함으로써 NullPointerException을 방지하자는 이슈였다.
- 선정 이유
변수 타입을 변경함으로써 기존에 발생하던 에러를 방지해주는 이슈였기에, 버그 fix 관점에서 매력적으로 느껴진 이슈였다. 하지만, 해당 이슈는 이미 6달전에 PR이 올라간 상태이지만, merge가 되진 않아서 더 보완할 점들을 찾아 새로운 pr을 전송해도 괜찮을지 궁금해서 일단 가져와봤다.
- 피드백
이미 다른분께서 PR을 만드신 상태였고, 아직 리뷰가 안된 것 같아서 섣불리 이슈를 골라서 작업하기가 어려웠다.
elasticearch
이슈 1
- 이슈 설명
HighlightBuilder 클래스에는 encoder가 있지만, HighlightBuilder.Field 클래스엔 없기 때문에, 검색 query의 fields 부분에 encoder 값이 인식되지 않는 이슈인 것 같았다.
- 선정 이유
결과적으로 선택한 오픈소스는 elasticsearch-java 이지만, 기여가 끝나고 나면 elasticsearch에도 도전해보고 싶어서 미리 이슈 하나를 선정해봤다. 인제님께서도 오픈소스 스터디 초반에 추천해주는 이슈이기도 해서 한번 살펴봤다.
POST http://localhost:9200/highlight-test-000001/_search
Content-Type: application/json
{
"query": {
"match": {
"string": {
"query": "text"
}
}
},
"highlight": {
"fields": {
"string": {
"encoder": "html"
}
}
}
}코드를 살펴보니 HighlightBuilder.Field 클래스에 encoder 정보를 추가해야 “[highlight_field] unknown field [encoder]” 에러가 없어진다고 추측 중 입니다. 하지만, 어떤식으로 추가해야할지 구체적으로는 갈피가 잡히지 않은 상태였기에, 해당 이슈에 대해 인제님으로부터 약간의 피드백 혹은 가이던스를 받을 수 있지 않을까라는 생각이 들었다.
- 피드백
/**
* `tags_schema` is not produced by toXContent in the builder but should be parseable, so this
* adds a simple json test for this.
*/
public void testParsingTagsSchema() throws IOException {
String highlightElement = """
{
"tags_schema" : "styled"
}
""";역시 인제님답게 테스트 코드를 사용하여 분석을 끝내신 상태셨다. 해당 코드를 살펴보며 highlightElement부분의 styled속성 때문에 해당 이슈가 발생하는 건 아닌지를 고민해보라고 하셔서 이쪽 부분을 중점으로 코드 해석을 진행해보기로 하였다.
최종 선정 이슈
첫 기여는 쉬운 이슈여야 재미를 붙일 수 있다는 인제님의 말씀을 듣고, 해결방법이 나름 명확하고 인제님의 추천까지 받은 이슈인 DisableUserResponse와 해당 클래스와 관련된 다른 클래스의 응답 형식을 수정하는 이슈를 선정하였다.
다음 회고 글에서는 코드 수정 방법과 기여 사항이 최종 승인된 결과까지 게시할 예정이다.